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Abstract 

OpenPGP, an IETF Proposed Standard based on PGP® 
application, has its own Public Key Infrastructure (PKI) 
architecture which is different from the one based on 
X.509, another standard from ITU. This paper describes 
the OpenPGP PKI; the historical perspective as well as 
its current use. We also compare three PKI technolo- 
gies standardized by IETF: OpenPGP, PKIX(X.509), and 
SPKI/SDSI. 

Since the OpenPGP PKI works without a registration 
authority nor certification authority, it fits well with the 
Internet communication with voluntary community. For 
example, the digital signature for email including the se- 
curity patch program of free software is usually signed by 
not an authorized organization but the cross-PGP-signed 
individuals who belong to different organizations or na- 
tions. 

The current OpenPGP PKI issues include the capabil- 
ity of a PGP keyserver and its performance. PGP key- 
servers have been developed and operated by volunteers 
since the 1990s. The keyservers distribute, merge, and ex- 
pire the OpenPGP public keys. Major keyserver managers 



from several countries have built the globally distributed 
network of PGP keyservers. However, the current PGP 
Public Keyserver (pksd) has some limitations. It does not 
support fully the OpenPGP format so that it is neither ex- 
pandable nor flexible, without any cluster technology. 

Finally we introduce the project on the next genera- 
tion OpenPGP public keyserver called the OpenPKSD, 
lead by Hironobu Suzuki, one of the authors, and 
funded by Japanese Information-technology Promotion 
Agency(IPA). 



1 Introduction 

Authentication is an essential factor of information se- 
curity in network society. The difficulty of building a 
Public-Key Infrastructure (PKI) is a major impediment to 
strong authentication. Without PKI, we cannot trust nei- 
ther digital signature nor certification based on the pubUc 
key cryptosystem via wide-area network. 

In following section |2] and |3l we overview the PKI ar- 
chitecture comparing several models. In section 0] we 
examine a PKI without authorities which is presented by 



the OpenPGP technology and compare it with the other 
models. Then we point out the role of the PGP key server 
in section |S] and introduce the next generation OpenPGP 
public keyserver project in section Q Finally we give 
some conclusions. 



2 PKI architectures 

PKI has three core functions as follows to manage the 
users' certification and trust relations |25 s.v. "public- 
key infrastructure"]: 

1. to register users and issue their public -key certifi- 
cates 

2. to revoke certificates when required 

3. to archive data needed to validate certificates at a 
much later time 

To operate these three functions with many users on a 
large-scale network, many PKI have a hierarchical struc- 
ture for CAs and are built using a centralized architecture. 
However there are alternatives. 

PKI is categorized by the architecture types as fol- 
lows: 1) hierarchical PKI, 2) mesh PKI, and 3) trust-file 
PKI L25i s.v. "trusted certificate"]. The difference is the 
way how they rely on CA (Certification Authority). A 
hierarchical PKI has the most significant CA in terms of 
trust at the root of the hierarchy tree. A mesh PKI has CAs 
issue cross-certificates to each other. A trust-file PKI has 
a local file of public -key certificates that the user trusts as 
starting points for certification chain. 

For example, popular browsers are distributed with an 
initial file of trusted certificates, the starting points for cer- 
tification paths. The initial file is different between among 
the each PKI architecture. In a hierarchical PKI, the ini- 
tial file is the root certificate in a hierarchical PKI. It is 
usually "baked into" the browsers with no decisions by 
the users to trust them. In a mesh PKI, it is the certificate 
of the CA that issued the user's own certificate. And in 
a trust-file PKI, any certificates including self-signed cer- 
tificates accepted by the user can be the first public key in 
a certification path. 



3 PKI standards 

To build PKIs, different standards are developed. They are 
based on their own framework and architecture and they 
are never the same. This section compares different PKI 
architecfiires: 1) X.509 standard from ITU, 2) OpenPGP, 
an IETF Proposed standard based on PGP® application, 
and 3) SPKI, another standards based on the theoretical 
research. 

X.509 is the earliest framework to provide and sup- 
port authentication including formats for X.509 public- 
key certificates, X.509 attribute certificates, and X.509 
CRLs. X.509 is the hierarchical PKI that a CA, central 
digital certificates issuer, is responsible for managing the 
certificates. 

Historically, X.509 was standardized by ITU-T (Inter- 
national Telecommunication Union Telecommunication 
sector, formerly CCITT) and turned to be ISO standard. 
X.509 follows the X.500 directory service and provides 
an example of reliable authentication and certification. In 
practice, developers relax the strict X.500 service scheme. 
For example, X.509v3 (Version 3) certificate has "exten- 
sions" field for flexible operation. 

IETF had discussed about the design based on X.509 
framework from each applications to general PKI. Inter- 
net standards for X.509 PKI framework is developed at 
IETF Public-Key Infrastructure (X.509) Working Group. 
PKIX not only profiles X.509 standards, but also develops 
new standards apropos to the use of X.509-based PKIs in 
the Internet. 

One of the most popular implemen- 
tations of X.509-based PKI is OpenSSL 
( |http : / /www . openssl . org/ | formerly SSLeay). 
OpenSSL is a set of Open Source cryptography libtaries 
including X.509 CA operation scripts and distributed 
freely, such as a part of PKI package for either commer- 
cial or non-commercial purpose. 

OpenPGP is the standard based on Pretty Good 
Privacy® (PGP®) application which is developed by 
Philip Zimmermann |12J. PGP® is provided as 
commercial version and 'freeware' version for non- 
commercial/non-governmental purposes only. 

The specification of PGP is standardized as OpenPGP 
by IETF OpenPGP Working Group. Today "OpenPGP 
Message Format" is defined in RFC2440 |3| and to be 
updated |4|. The most popular OpenPGP implemena- 
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tion is GnuPG (GNU Privacy Guard), developed by Free 
Software Foundation and maintained by Werner Koch 
of GUUG (German Unix Users Group). Either PGP or 
GnuPG has been known as email cryptography software 
firstly, however they has become the general purpose data 
encryption tool, including key exchange over Internet, 
trust computation, etc. In the following sections, we ex- 
amine the only PKI part of OpenPGP. 

It is worth to point out another possible architec- 
ture, as we sometimes take an closed binary question 
such as "X.509 or OpenPGP, which is better?", not as 
"Which PKI will be the appropriate solution for differ- 
ent usage-scenarios?". There exists another PKI stan- 
dardized by IETF — SPKI (Simple Public Key Infras- 
tructure). IETF SPKI Working Group finished its initial 
standardization process and bring into the inter-operation 
stage 1 16 10 1. It is also called SPKI/SDSI as it is a joint 
force with SDSI (Simple Distributed Security Infrastruc- 
ture) research. SPKI is designed with distributed and scal- 
able architecture in many aspects, i.e., no single root CA, 
no globally distinguished name, and flexible validity pe- 
riods HTIpil. 

Table |2l shows the technical comparison of X.509, 
OpenPGP and SPKI/SDSI based on the analysis by 
Clarke 

4 Certification without Authority 

4.1 From Face-to-Face to Web of Trust 

Without a certification authority, the problem of trusting 
keys arise to assess applicants before giving out certifi- 
cates. In OpenPGP, there are no official mechanism for 
creating certificates, no officail channel for acquiring and 
distributing. It makes the process of certification into the 
face-to-face, ad hoc situation. Each end user is respobsi- 
ble to decide which certificate (public key of an user) is 
trusted and accepted to be added into their local trust-file 
(denoted "keyring" in PGP). 

This certification process does not require a trusted, 
monitored registration authority or certification authority, 
however, it lacks scalability. So since PGP® 2.0 |15 
pp. 201-203], "web of trust" model that PGP signer acts 
as an introducer between people had been supported. 

Figure [0 illustrates the model of hierarchical PKI and 



web of trust. 




Figure 1 : Hierarchical PKI and Web of Trust fS^ 



4.2 Internet Usage Scenarios 

OpenPGP has its own market which is different with 
X.509, and OpenPGP community has grown in a global 
Internet. 

The most famous and critical use might be security 
alerts. FIRST (Forum of Incident Response and Security 
Teams) and its members including CERT(Computer 
Emergency ResponseTeam)/CC(Coordination Center) 
have their official PGP/GnuPG public keys publicly 
available fl l], and have signed their alerts with their own 
PGP/GnuPG key. 

Usenet, operated by volunteer NetNews managers, 
is another example of the distributed network with 
OpenPGP PKI. The digital signature for Usenet control 
commands should be signed with PGP keys of represented 
voluntary managers since 1990s L14I . 

4.3 What is the Web of Trust? 

OpenPGP provides key management and certificate ser- 
vices using local trust-file PKI. The more signature is ac- 
cepted, the more trust-file generated. Figure|2is an exam- 
ple of a trust-file visualized the relashonship of OpenPGP 
signature. This graph illustrates who introduce the other 
or who meets with face-to-face, in other words, whose key 
signed the others' public key. There are no central author- 
ities but multiplexed indivisual relationships in a commu- 
nity. 
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Figure 2: Visialized Web of Certificate (8] 



However, this graph is not a "web of trust" but just a 
"web of certificates". OpenPGP separate the trustworthy 
from vaHdity of cerfiticate. For example, the amount of 
trust of the introducer and unknown newcomer is different 
for an OpenPGP user. Even if their certification is valid, 
the issuer of the key is not an authority but the users own. 
So OpenPGP users should be responsible on "Whose keys 
should be taken as valid but untrusted?" P- 81]. 

In OpenPGP, users issue their signature to the other's 
public key with their degree of trust. This is denoted "trust 
signature" and represented as (trust level, trust amount) 
with OpenPGP key management and certificate service. 
An ordinary valid signed key is trust level 0, and The 
signed key is asserted to be a valid trusted introducer is 
level 1 . Level 2 means "meta introducer" or "introducer- 
of-introducer" that its signed key is asserted to be trusted 
to issue level 1 trust signatures. (Generally, as the intro- 
ducer is more trustworthy, a level n trust signature asserts 
that a key is trusted to issue level n — 1 trust signatures.) 
The trust amount is in a range from 0-255, and appointed 
60 for partial trust and 120 for complete trust |3, s.v. 
"Trust Signature"]. As OpenPGP distinguished the trust 
from validity, "web of trust" is also distinguished from 
"web of certificates". 



4.4 PGP Revocation Problem 

The weakest hnk of OpenPGP PKI is the revocation of 
pubhc key flT pp. 585-586] |9 , p. 309]. As there is no 
official channel for acquiring and distributing OpenPGP 
public keys, there are no guarantee about how to tell ev- 
eryone that your key is no longer valid. 

The typical answer to this revocation problem of PGP is 
to use PGP public keyserver for distributing certification. 
"Typically, to communicate that a certificate has been re- 
voked, a signed note, called a key revocation certificate, is 
posted on PGP certificate servers, and widely distributed 
to people who have the key on their public keyrings. Peo- 
ple wishing to communicate with the affected user, or use 
the affected key to authenticate other keys, are warned 
about the hazards of using that public key" fT pp. 56- 
57]. However, there are few research on the PGP public 
keyserver and usually the keyserver is not considered as 
the part of OpenPGP PKI. In the following, this paper ex- 
amines PGP keyserver as the part of OpenPGP PKI. 

5 Related Works 

There are several research fields related to OpenPGP pub- 
lic keyserver The first is the study on the traditional PGP 
public keyservers, the second is the integrated channel for 
OpenPGP key distribution, and the third is the combined 
"web of trust" with other PKI. 

A "web of trust" used in PGP is referred in several 
researches including the peer-to-peer authentication l"^, 
trust computation [17, .5.1. and privacy enhanced technol- 
ogy IIT2I . However, there are few description on PGP key- 
server. It might be because PGP keyserver mechanism is 
too simple. It is not a CA but just a pool of public keys. 
From users' viewpoint, PGP keyserver has a large amount 
of OpenPGP public keys that provide the interesting mate- 
rial for social analysis of network community. For exam- 
ple, OpenPGP keyserver developer Jonathan McDowell 
also developed "Experimental PGP key path finder" 
that searches and displays the chain of certification be- 
tween the users. 

As OpenPGP's initial trust file is blank, the users have 
to start with a face-to-face certificate to exchange pub- 
lic keys. Though another initial file is provided via high 
integrity channel. Global Internet Trust Register ||2| is 
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a printed book that contains "fingerprints" (hash values 
of certificate) of the most important pubHc keys (mainly 
cryptography experts who are likely to have signed many 
other keys in their respectice communities) |26 pp. 80- 
81]. 

OpenPGP PKI itself can be described as the superset of 
PKI 1321 . however, combining OpenPGP PKI with other 
authentication system is challenging work in both theoret- 
ical and operational field. Formal study of trust relation- 
ship of PKI started in the late 1990s 1 17 5 1 and GnuPG 
development version in December 2002 started to support 
its trust calculation with GnuPGP's trust signature. 

The implementation of trust calculation is ongoing and 
using large-scale "web of trust" (not "web of certificates") 
is not so popular outside of computer experts. On the 
other hands, using different types of PKI has become 
more popular 

In the early work at MIT, PGP-signing service had been 
combined with Kerberos CA system that does not have 
public key cryptography 12 1 il . Today, the hybrid sys- 
tem of OpenPGP and X.509 is both developed into some 
OpenPGP implementations. In 2001, German authorities 
BSI (Bundesamt fiir Sicherheit in der Informationstech- 
nik, Germany's agency for information technology secu- 
rity) accept the Agypten project for Open Source imple- 
mentation of governmental mail user agents Sphinx which 
supports X.509v3, PKCS, LDAP and OpenPGP llT9l . 
The results of the open development are begun to im- 
ported to other commercial products in 2002-2003 |23|. 
In a same way, PGP Corporation also released PGP® ver- 
sion 8.0 as X.509-enabled application that can interoper- 
ate X.509 certificates and CAs 1201. 



6 OpenPGP Public Keyserver 

Before describing our research, this section describes 
OpenPGP keyserver generally. Keyserver is not a CA. 
It only pool anyone's public keys. Keyserver never issue 
any certificate for someone's public key but only provide 
it. 



6.1 Current Status 

The first keyserver is developed at MIT in 1994 
by Brian A. LaMacchia. It exchange public keys 



with email and keys are managemented with PGP 
command. For users, keyserver acts as an easy 
email agent who receives any valid but untrusted 
keys, then searches and provides the key to ev- 
eryone. In 1997, PGP Pubhc KeyServer (p ksd, 
ihttp: / / www.mit . edu/ people/marc/pks/t 
started by MIT student Marc Horowitz. Pksd uses a 
database management system and has been working fine. 
The database system is operated via email, CGI-interface 
from http server, and HKP — pksd's own communication 
protocol over Hypertext Transfer Protocol (HTTP). 
In 2003, David Shaw of GnuPG team proposed the 
OpenPGP HTTP Keyserver Protocol |24| based on 
traditional HKP as the draft for Internet Standard. 

Today pksd has been working fine even if in global 
distributed network. There are 10 or more syncronized 
public keyservers in the world and the most of them are 
running with patched pksd. These public keyservers are 
operated by voluntary managers belong to organizations 
including MIT and Georgia Tech in United States, 

in Germany, 
in Japan. To- 



SURFnet in Netherlands, DFN-CERT 



RedlRIS (IRIS-CERT) in Spain, JPNIC 



day they have more than 1,400,000 public keys entries 
and 3,000/day or more transactions between each sync 
sites. In 2000, SURFnet held the first PGP keyserver man- 
ager symposium 1271 and the managers keep in touch with 
each other. 



6.2 Revocation process and Keyserver 

As public keyservers provides semi-official key dis- 
tribution channel, keyserver adds powerful feature to 
OpenPGP PKI. Public keyservers can handle the PGP re- 
vocation problem that we described in section l4~4l Using 
keyserver provides an answer to the question "How do 
you tell everyone that your key is no longer valid?". User 
may issue a suicide note (denoted as "revocation signa- 
ture" in OpenPGP ) and post it to keyservers. Receiving 
a valid revocation signature, keyserver updates the key to 
be revoked. The update key with revocation signature is 
redistributed to the synchronized keyservers in the world, 
and finally PGP user updates their keyrings with the near- 
est keyserver The updated key with valid revoked signa- 
ture makes users's older key not to be used. 
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6.3 Current Keyserver Problem 

Today's sisutation around PGP keyserver is beyond the 
original developers' idea, and current pksd also has some 
limitations. 

Firstly, the implementations of pksd are not OpenPGP- 
compliant. OpenPGP |3| published in 1998 defines 
two versions of signature formats. (Version 3 pro- 
vides basic OpenPGP signature information, while ver- 
sion 4 provides an expandable format with subpackets.) 
These changes made traditional PGP applications not- 
OpenPGP-compliant — not only PGP® 1 3 s.v. "Imple- 
mentation Nits"] but also pksd. Today pksd does not fully 
support OpenPGP format. 

Seconary, the pksd does not scalability for global use. 
Though pksd has simple but strong dabatabase manage- 
ment system, it is neither soshisticated nor scalable com- 
pared with today's Internet server. For the matter, pksd 
cannot handle 1 billion keys and cannot accept such many 
transactions as Yahoo! or eBay site. New design of 
OpenPGP public keyserver is required. 

7 OpenPKSD: Next Generation 
OpenPGP Public Keyserver 

We introduce our next generation OpenPGP Public Key- 
server project with a new architecture. We call it 
OpenPKSD ( OpenPGP Public KeyServer Daemon). 
It is developed by one of the authors and funded 
by Japanese Information-technology Promotion Agency 
(IPA) in 2001-2002. 

7.1 Server Design and Implementation 

OpenPKSD supports OpenPGP subpacket format and 
works as high-performance server with SQL backend. 
The design of OpenPKSD oriented to not only high- 
performance, but also flexible extension capability and 
easy operation. We implemented OpenPKSD with Ruby 
and PostgreSQL backend [28J. 

7.2 User Interface and Security 

As "Web of trust" depends on users' decision, user in- 
terface is also important factor on security. For example. 



Whitten and Tygar 1311 had ever pointed out some dan- 
gerous errors occured with past PGP clients' interface. 

Users can connect to OpenPKSD with two kind of in- 
terfaces, OpenPGP client or CGI on WWW. Providing 
WWW interface, OpenPKSD must help users' recogniza- 
tion, judgement, and handling on OpenPGP public keys. 

OpenPKSD displays only 64bit KeylD to identify 
someone's public keys. Though some other servers calcu- 
late and display "fingerprint" of public keys before down- 
load it, it does not help users arare of risk using keyserver 
As keyserver is just a pool and not CA, users should check 
the public key with their own. Moreover, it is easy to 
make some faked keyserver by Man-in-the-Middle At- 
tack, TCP hijacking, etc. It means that the fingerprint 
must be calculated under user's (safe) machine and that is 
the reason why OpenPKSD does not display fingerprint. 

OpenPKSD WWW interface provides additional fea- 
ture to visualize subpackets of PGP keys. As OpenPKSD 
has an expandable format with subpackets, it is very hard 
to understand the data structure inside this. Using pg- 
pdump program, key packet visualizer that displays the 
packet format of OpenPGP and PGP® version 2. 

Many PGP users are familiar with this verification on 
added keys, as in 2000, PGP® version 5.5.x to 6.5.3 had 
a serious security hole that cannot detected with finger- 
print verification. Then CERT/CC had alarted "Check 
certificates for ADKs [Additional Decryption Keys] be- 
fore adding them to a keyring." 1 6 1 Pgpdump exactly visu- 
alizes these additional keys. With pgpdump, OpenPKSD 
helps users to recognize the information of public key and 
any other added keys before downloading. 

7.3 Performance and Future work 

OpenPKSD is implemented with Ruby language and 
PostgreSQL DBMS. Ruby is so-called "scripting lan- 
guage" and seemed not suitable for a quick response 
or large program development. However, OpenPKSD 
succeeds not only the more compact code size but also 
quick response compared with pksd, by loading bit cal- 
culation modules such as CRC24 checksum written by 
C language |29i . Table ^ shows the performance of 
OpenPKSD version 0.2.8, non-cluster version, installed 
on PC. OpenPKSD version 0.2.8 is also working well at 
handling usual transaction between other PGP public key- 
server described in section|6lsince 2002. 
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CPU: 


Intel Pentium4 1.6GHz 


HDD: 


IDE ATA 100 7200rpm 60GB 


Memory: 


PC2100 768MB 


One key query: 


120ms average, 

72ms best, 
230ms worst. 



Table 1 : OpenPKSD Performance 



Forthcoming developers' version of OpenPKSD will 
support some clustering based on the reserch on the per- 
formance of cluster technology 1301 . It will be published 
in 2003 and support the experimental HKP(keyserver pro- 
tocol over http) balancer, keyserver cluster, and clustered 
database. 

8 Summary 

In this paper, we overlooked some PKI architectures. Us- 
ing "Web of Trust," OpenPGP PKI can help users to man- 
age certification without CAs. However, there are the 
problem on public key management, i.e., how to get the 
receivers' public key, or, how to tell everyone that the pub- 
lic key is no longer valid. PGP keyserver is the solution 
to the problem. 

Though some PGP public keyservers have built a global 
PKI, traditional PGP keservers have some limitations. We 
introduced OpenPKSD, newly-designed and OpenPGP- 
supported public keyserver project. OpenPKSD took its 
first step, works well in practice, and examining the clus- 
ter technology. 

Availability 

OpenPKSD source code and documents are avail- 
able under GNU General PubUc License (GPL) at 
ihttp : / / www . openpksd . orq/| 
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X.509 


CA Characteristics: 


Global Hierarchy. There are conmiercial X.509 CAs. 
X.509 communities are built from the top-down. 




Trust Model: 


Hierarchical Trust Model. Trust originates from a 'trusted' 
CA, over which the guardian may or may not have control. 
A requestor provides a chain of authentication from the 
'trusted' CA to the requestor's key. 




Signatures: 


Each certificate has one signature, belonging to the issuer 
of the certificate. 




Certificate Revocation: 


Uses CRL(Certificate Revocation List)s 




Name Space: 


Global 




Types of Certificates: 


Name Certificates 




Name-to-Key binding: 


Single- valued function: each global name is bound to ex- 
actly one key (assuming each user has a single public- 
private key pair). 


OpenPGP 


CA Characteristics: 


Egalitarian design. Each key can issue certificates. 
PGP communities are built from the bottom-up in a 

distributed manner. 




Trust Model: 


Web of Trust, file-based PKl. 




Signatures: 


Each certificate can have multiple signatures; the first 
signature belongs to the issuer of the certificate. 




Certificate Revocation: 


A 'key revocation certificate' suicide note is posted on 
PGP keyservers, and widely distributed to people who 
have the compromised key on their pubUc keyrings. 




Name Space: 


Global 




Types of Certificates: 


Name Certificates 




Name-to-Key binding: 


Single-valued function: each global name is bound to ex- 
actly one key (assuming each user has a single public- 
private key pair). 


SPKI/SDSI 


CA Characteristics: 


Egalitarian design. The principals are the public keys. 
Each key can issue certificates. SPKl/SDSl communities 
are built from the bottom-up in a distributed manner. 




Trust Model: 


Trust originates from the guardian. A requestor provides 
a chain of authorization from the guardian to the 

requestor's key. The infrastructure has a clean, scalable 
model for defining groups and delegating authority. 




Signatures: 


Each certificate has one signature, belonging to the issuer 
of the certificate. 




Certificate Revocation: 


Advocates using short vaUdity periods and Certificates of 
Health. 




Name Space: 


Local 




Types of Certificates: 


Name Certificates, Authorization Certificates 




Name-to-Key binding: 


Multi-valued function: each local name is bound to zero, 
one or more keys (assuming each user has a single public 
-private key pair). 



Table 2: Comparison of X.509, OpenPGP, and SPKI/SDSI 



9 



